1. Field of the Invention
The present invention relates to the field of content presentation by a digital rendering system such as a digital media player.
2. Related Art
Most traditional digital rendering systems, such as RealNetworks® RealPlayer® digital media players, maintain an internal variable during playback of media content that reflects a current presentation time (hereafter referred to as “Current Time”). Current Time is, in effect, a current “position” in the media content that is being displayed and rendered. Typically Current Time is set to zero at the beginning of the media content, and it reaches a measure of time equal to a duration of presentation of the content of the entire work when the end of the media content is reached.
In most traditional players, such as the RealPlayer® digital media player, a Current Time value is: (a) regularly calculated by a single module; (b) acquired and stored by core routines of the player; and (c) distributed to, and utilized by, various internal player objects. These internal objects utilize the Current Time value to determine when it is time to initiate or terminate various tasks associated with media content playback. The calculation of a Current Time value by the single module, and the distribution to, and utilization by, multiple objects within a player of the same Current Time value has a desirable result of keeping all objects synchronized.
Typically the Current Time value must be regularly and accurately updated by the player, or the presentation of media content will be faulty. For instance, if the Current Time value is not updated sufficiently often, a video component of a media stream may appear uneven or jumpy, and gaps in an audio content may be audible.
Although the concept of Current Time seems straightforward, in fact, it conflates two subtly different properties of media playback. The first property of media playback that is conflated in the concept of Current Time is a time elapsed since the beginning of the media content presentation (hereafter called “Presentation Time”). Thus, if the media has been playing for one minute, the value of Presentation Time is 60,000 milliseconds. All of time values discussed herein can be measured in various units. Two popular units are milliseconds, and centi-nanoseconds, or 1/10,000,000 of a second. The unit of measurement is not an issue here. Other considerations of representing time that are not issues here are the precision, the range of values, and the format of the representation.
The second property of media playback that is conflated in the concept of Current Time is a location in the media content stream that is currently being played (hereafter called “Content Time”). In a traditional linear media stream that is always played back at a fixed, “normal” rate, any given content element is always presented after a fixed amount of time has elapsed from the beginning of playback. Because of this, each such content element can be regarded as having a timestamp associated with it, i.e., a time value specifying how long it would take to reach that location, starting from the beginning of the media content, and playing at normal rate. Hereinafter we will call this property “Data Time.”
Presentation Time and Data Time are identical in traditional players, because traditional players can only present media content at a fixed “normal” rate. However, when a player is enhanced with a Time-Scale Modification (TSM) capability, it can present media content at various rates. Because of this, Presentation Time and Data Time are no longer the same. For example, if a 60-second clip of media content is presented at a fixed rate that is twice normal rate, at the end of the clip the Data Time is 60,000 milliseconds, but the Presentation Time is 30,000 milliseconds. This is because it only takes 30 seconds to play the 60-second clip.
We have discovered that problems may occur when a traditional player is enhanced with TSM functionality. In particular, if a Current Time value is distributed to multiple objects, some of them may interpret the Current Time value as specifying Data Time, some of them may interpret the Current Time value as specifying Presentation Time, and some of them may interpret the Current Time value as specifying both Data and Presentation Time. Thus, a first problem occurring when a traditional player is enhanced with TSM functionality is that the significance of the time value distributed to multiple objects is, in general, ambiguous. A second problem occurring when a traditional player is enhanced with TSM functionality is that Data Time does not, in general, equal Presentation Time, and the calculation, storage, and distribution of a single time value is inadequate to specify both values.
It is quite common for media players to rely on an audio renderer (for example, a player object responsible for outputting audio content through, for example, a computer sound card) to calculate and update the Current Time value. This is done because the nature of audio representation is such that typically each audio data element has either a fixed, or explicitly specified presentation duration, associated with it, and these presentation durations are enforced by audio rendering hardware. Therefore, the audio renderer can typically determine Presentation Time either by maintaining a running total of the presentation durations of all audio data elements rendered since playback began, or in some cases by querying the audio rendering hardware itself for the equivalent value.
If a media player does in fact acquire the Current Time value from the audio renderer, the value that the audio renderer will return to the system will typically be the Presentation Time. Since most of the rest of the system needs Data Time, most of the rest of the system can no longer employ the value returned by the audio renderer object.
As one can readily appreciate from the above, a need exists in the art for a method and apparatus for solving one or more of the above-described problems.